1. Technical Field
This disclosure relates generally to techniques to enable non-interactive-based integration among applications sharing a common, token-based authentication system without a user necessarily being present.
2. Background of the Related Art
In a traditional client-server authentication model, a client uses its credentials to access resources hosted by a server. With the increasing use of distributed web services and cloud computing, third-party applications often require access to these server-hosted resources. OAuth is an open protocol (Internet Request for Comment (RFC) 5849) that enables users to share their private data among different Web sites along with their credentials while only exposing the data on the original Web site where it is held. In particular, the OAuth protocol allows users to share private resources stored on one Web site with other sites without exposing the users' credentials—for example, usernames and passwords—to Web sites other than the one holding the users' data. A Web site adopting OAuth as one of its authentication protocols enhances the privacy and security for users. To accomplish this functionality, OAuth introduces to the traditional client-server authentication model a third role, a resource owner. In the OAuth model, the client (which is not the resource owner, but is acting on its behalf) requests access to resources controlled by the resource owner but hosted by the server. In addition, OAuth allows the server to verify not only the resource owner authorization, but also the identity of the client making the request.
An emerging information technology (IT) delivery model is cloud computing, by which shared resources, software and information are provided over the Internet to computers and other devices on-demand. Cloud computing can significantly reduce IT costs and complexities while improving workload optimization and service delivery. With this approach, an application instance can be hosted and made available from Internet-based resources that are accessible through a conventional Web browser over HTTP. An example application might be one that provides a common set of messaging functions, such as email, calendaring, contact management, and instant messaging. A user would then access the service directly over the Internet. Using this service, an enterprise would place its email, calendar and/or collaboration infrastructure in the cloud, and an end user would use an appropriate client to access his or her email, or perform a calendar operation.
While the above-described solution provides many advantages, it has not been possible to integrate on-premises non-interactive services with cloud-based authentication systems that expect the end user to be present. Thus, for example, suppose a cloud customer operates on-premises a customer relationship management (CRM) application and a first user takes an action therein (e.g., identifying a new sales opportunity); that action might normally be expected to generate some desired outcome in the cloud service, such as causing a new “to do” activity to be created in the service for a second user—but only if the second user's credentials are available upon invocation. If the cloud service uses a scheme that requires an invoker to present the user's credentials (or, as in OAuth, requires an authorized token to invoke requests), this task cannot be implemented in an automated manner. While it is possible to address this requirement by storing all user credentials for the cloud service, this is insecure and undesirable.
Thus, there remains a need to provide a technique by which a trusted service can access a hosted service on behalf of a user in the user's absence. This disclosure addresses this need.